Methods and Apparatus for Managing Asynchronous Dependent I/O for a Virtual Fibre Channel Target

ABSTRACT

A system and method for arbitrating exchange identifier assignments for I/O operations are disclosed. In an exemplary embodiment, the method comprises receiving, by a storage system, a data command from a host system. The data command is directed to a virtual device of the storage system, the virtual device comprising a plurality of physical devices of the storage system. A range of exchange identifier values are allocated to the data command. The range may include a predefined number of exchange identifiers, the predefined number determined prior to the receiving of the data command. A plurality of I/O operations corresponding to the data command are issued, where each of the plurality of I/O operations is directed to a physical device of the plurality of physical devices of the storage system. An exchange identifier within the range of exchange identifier values is associated with each of the plurality of I/O operations.

RELATED PATENTS

This patent is a continuation of U.S. Ser. No. 12/761,452 filed Apr. 16,2010, now U.S. Pat. No. ______, and entitled “METHODS AND APPARATUS FORMANAGING ASYNCHRONOUS DEPENDENT I/O FOR A VIRTUAL FIBRE CHANNEL TARGET”and is related to commonly owned U.S. Ser. No. 12/761,270 filed Apr. 15,2010 and entitled “METHODS AND APPARATUS FOR CUT-THROUGH CACHEMANAGEMENT FOR A MIRRORED VIRTUAL VOLUME OF A VIRTUALIZED STORAGESYSTEM,” the entire disclosure of each of which is incorporated hereinby reference in its entirety.

BACKGROUND

1. Field of the Invention

The invention relates generally to Fibre Channel (FC) systems and morespecifically relates to improved methods and apparatus for managingvirtual FC targets using multiple, asynchronous dependent physical I/Otransactions.

2. Discussion of Related Art

It is generally known for storage subsystems to provide a layer ofvirtualization that hides the physical characteristics of underlyingstorage devices from attached host systems. For example, RAID storagemanagement techniques may define a logical volume distributed overmultiple physical disk drives (e.g., “striped” and/or “mirrored”) whilepresenting a single logical unit (e.g., logical volume or virtualvolume) to attached host systems. RAID storage management controllerdevices associated with the disk drives perform the logical/virtual tophysical mapping to permit access to the storage capacity.

In the context of virtualized storage using Fibre Channel (FC)communications, a Data Path Manager (DPM) module may cooperate with aStorage Virtualization Manager (SVM) to provide the desired mapping froma virtual FC target (e.g., a logical volume or virtual volume) to one ormore physical FC target devices (e.g., portions of one or more physicaldisk drives). In such a context, a host initiated read or write commandis communicated over the Fibre Channel fabric to a DPM which, in turn,produces a virtual to physical I/O command tree used to issue one ormore commands to appropriate physical FC target devices. In such DPM/SVMFibre Channel environments, a typical translation from the virtual I/Orequest to corresponding physical I/O may generate a simple, single I/Ooperation to a single physical target device or may generate multiplephysical I/O operations to multiple physical target devices.

In accordance with Fibre Channel standards, an exchange identifier (XID)is associated with the each of the one or more physical I/O operationsto associate the operations with the original host initiated read orwrite command. Where a host initiated read or write command results inmultiple physical I/O operations, the exchange ID for each such physicalI/O operation is typically allocated from a pool of available X IDvalues. The multiple X ID values allocated for the multiple physical I/Ooperations are then associated with one another so that the DPM candetermine when all physical I/O operations corresponding to a virtual FCtarget read or write have completed. Further, when all of the multiplephysical I/O operations completed, all associated XID values for a givenvirtual FC target read or write command can be released for re-use.

Where multiple physical I/O operations are issued in a sequential manner(each subsequent operation waiting for a preceding operation tocomplete), each X ID may be allocated as needed in sequence from thepool of available X ID values. One of the allocated X ID values (e.g.,the first or the last) is then used in the FC response sent back to therequesting host system. Management of the multiple X ID values where thecorresponding multiple physical I/O operations are issued in asequential manner often uses a queue structure (e.g., linked list datastructure) to maintain the pool of available X ID values. A similar liststructure may be used to associate the multiple XID values associatedwith a single virtual target read or write command.

In some storage management subsystems, such as RAID level 1 (mirrored)RAID level 5 (striped), data may be more effectively processed byissuing multiple parallel I/O operations to the multiple physical FCtarget devices corresponding to the virtual FC target addressed by thehost initiated read or write command. The multiple physical I/Ooperations are considered “dependent” in that all must complete in somemanner to complete the underlying request directed to the virtual FCtarget. Although such parallel I/O operations are favored for optimalperformance, in the context of virtual Fibre Channel targets, themultiple exchange ID values utilized for the dependent, multiplephysical I/O operations must be carefully managed because the multipleparallel I/O operations may be completed asynchronously with respect tothe one another. In other words, a first physical I/O operation may bedirected to a first physical target utilizing a first exchange ID in theFibre Channel media and a second physical I/O operation may be directedto a second physical target utilizing a second exchange ID in the FibreChannel media. However, the second physical I/O operation may completebefore the first physical I/O operation due to the asynchronous natureof the parallel operation of the multiple physical targets. The exchangeID corresponding to the second I/O operation (the first physicaloperation to complete) may generate confusion and complexity indetermining the ultimate status of each of the multiple physical I/Ooperations corresponding to the host initiated read or write command.Complex logic and data structures may be required to determine whichexchange IDs are related to the same underlying virtual targetoperation. This added complexity may be reflected in additional memoryaccesses to manage the list structures associated with the availableX_ID pool and/or with the list structures associating the multipleallocated X_ID values related to a single read/write command to avirtual target.

Thus, it is an ongoing challenge to manage asynchronous dependent I/O inthe context of a virtual Fibre Channel target and more specifically anongoing challenge to manage the exchange ID values utilized wheremultiple physical I/O operations are performed substantially in parallelresponsive to a host initiated read or write command directed to avirtual Fibre Channel target.

SUMMARY

The present invention solves the above and other problems, therebyadvancing the state of the useful arts, by providing methods andapparatus for managing exchange IDs for multiple asynchronous dependentI/O operations generated for virtual Fibre Channel (FC) target volumes.Features and aspects hereof allocate a range of sequential exchange IDvalues to be used for the multiple, asynchronous, dependent I/Ooperations directed to multiple physical FC targets of a virtual FCtarget. A primary X_ID is selected from the range of allocated X_IDvalues for communications with the attached host system that generatedthe original request to the virtual FC target volume.

In one aspect hereof, a method is provided operable in a virtualizedstorage system utilizing Fibre Channel (FC) communications. The storagesystem comprising a plurality of physical FC target devices. The methodcomprises receiving a read or write command over an FC communicationmedium from an attached host system. The read or write command isdirected to a virtual FC target that comprises multiple physical FCtarget devices. The method also comprises allocating a range ofsequential exchange identifier (X_ID) values responsive to receipt ofthe read or write command. The method then includes issuing multiplephysical I/O operations, each physical I/O operation directed to acorresponding one of the multiple physical FC target devices. Each ofthe multiple physical I/O operations is associated with a correspondingX_ID value of the range of sequential X_ID values. The method alsoselects a primary X_ID (RX_ID) value based on the X_ID value associatedwith a first completed physical I/O operation of the multiple physicalI/O operations and transmits a response to the host system indicatingsuccess or failure of the read or write command based on the completionof the multiple physical I/O operations. The response transmitted tohost system utilizes the RX_ID. The method then releases the allocatedrange of sequential X_ID values responsive to transmitting the responseto the host system.

Another aspect hereof provides apparatus in storage controller of avirtualized storage system. The system comprising a virtual FibreChannel (FC) target that comprises a plurality of physical FC targetdevices. The apparatus comprises a virtual I/O processor coupled withthe plurality of physical FC target devices. The virtual I/O processoradapted to receive a host initiated read or write command directed tothe virtual FC target and adapted to allocate a range of sequentialexchange ID (X_ID) values in response to receipt of the read or writecommand. The virtual I/O processor further adapted to issue multiplephysical I/O operations to the plurality of physical FC target deviceswhere each physical I/O operation includes a corresponding X_ID from therange of sequential X ID values. The apparatus further comprises aprimary exchange selection component coupled with the virtual I/Oprocessor and coupled with the plurality of physical FC target devices.The primary exchange selection component adapted to select a primary XID (RX ID) value based on the X_ID value associated with a firstcompleted physical I/O operation of the multiple physical I/Ooperations. The apparatus further comprises an I/O completion componentcoupled with the virtual I/O processor and coupled with the plurality ofphysical FC target devices. The I/O completion component adapted todetermine success or failure of the read or write command based on thecompletion of the multiple physical I/O operations and further adaptedto communicate the success or failure to the virtual I/O processor. Thevirtual I/O processor further adapted to transmit a response to the hostsystem indicating success or failure of the read or write responsive tothe communication from the I/O completion component wherein the responsetransmitted to the host system utilizes the RX ID. The virtual I/Oprocessor further adapted to release the allocated range of sequential XID values responsive to transmitting the response to the host system.

Still another aspect hereof provides a method operable in virtualizedFibre Channel (FC) storage controller. The controller adapted to couplewith one or more host systems and adapted to couple with a plurality ofphysical FC target devices. The method comprises defining, within thestorage controller, a plurality of ranges of exchange identifier (X_ID)values wherein each range comprises a number (N) of sequential X_IDvalues. The method also comprises receiving from a host system a read orwrite command directed to a virtual FC target. The virtual FC targetcomprising a portion of each of the plurality of physical FC targetdevices. The method also comprises allocating, responsive to receipt ofthe command, a selected range from the plurality of ranges and issuingmultiple physical I/O operations. Each physical I/O operation directedto a corresponding one of the plurality of physical FC target devices.Each of the multiple physical I/O operations is associated with acorresponding X ID value of the allocated range. The method thencommunicates with the host system to complete processing of the commandwherein the communication with the host system comprises a primary X_IDvalue selected from the allocated range. The method then releases theallocated range responsive to completing processing of the command.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary virtualized FC storagecontroller enhanced in accordance with features and aspects hereof toimprove management of exchange IDs used to associate multiple,asynchronous, dependent physical I/O operations associated with avirtual FC target.

FIG. 2 is a flowchart describing an exemplary method in accordance withfeatures and aspects hereof to improve management of exchange IDs usedto associate multiple, asynchronous, dependent physical I/O operationsassociated with a virtual FC target.

FIGS. 3 through 9 are flowcharts providing exemplary additional detailsof steps of the method of FIG. 2 in accordance with features and aspectshereof.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a virtualized storage controller 100enhanced in accordance with features and aspects hereof to provideimproved management of Fibre Channel exchange IDs when utilizingasynchronous, dependent, physical I/O operations. Virtualized storagecontroller 100 is sometimes referred to as a Data Path Manager (DPM) asexemplified by commercialized products such as the 8400 DPM produced andsold by LSI Corporation. Controller 100 receives and processes I/Orequests directed to storage volumes defined and managed by thecontroller 100. Virtualized storage controller 100 includes a datamanagement layer 102 responsible for defining virtual volumes asconfigured by an administrative user utilizing a Storage VirtualizationManagement (SVM) application program (not shown). The data managementlayer 102 is involved at the highest level for I/O requests in the sensethat it maintains mapping information used to map logical addressesassociated with defining a virtual volume into corresponding physicaladdresses on physical FC target devices (e.g., physical target drives160.1 through 160.N.). Devices 160.1 through 160.N may be any devicesadapted to serve as FC target devices including, for example storagedevices and in particular disk drives.

Virtualized storage controller 100, as a matter of design choice, mayinclude a mixture of custom circuit components (“hardware”) and softwarecomponents (stored in a computer readable medium and executed by asuitable processor—not shown) for processing I/O requests received fromone or more host systems 150. For example, elements 102 through 110(discussed further below) may be implemented as software components.Customized circuits 130 arc adapted to perform the lower-level I/Ooperations enhance the performance of the DPM in processing read andwrite commands. Such a design may be referred to as a “split-path”design in that some operations may be performed primarily by dedicatedhardware—e.g., customized circuits—while other operations may beperformed by some combination of software functions and hardwarefunctions.

Customized circuits 130 may include a virtual I/O processor 120 adaptedto receive I/O requests from host (initiator) 150 directed to a virtualvolume stored on physical target drives 160.1 through 160.N. Host 150may be a computing device or any other device adapted to initiaterequests for access to a virtual FC target device. Virtual I/O processor120 interacts with software components 102 through 110 to determinewhether the received host request may be rapidly processed primarilywithin the virtual I/O processor 120 or rather requires intervention andinteraction by the various software components of the virtualizedstorage controller 100. Virtual I/O processor 120 is sometimes referredto as a “fast path” of virtualized storage controller 100 in that manyI/O requests (e.g., read and write commands) received from host 150 maybe processed essentially entirely by the virtual I/O processor 120without requiring intervention by the various software components of thevirtualized storage controller 100.

Virtual I/O processor 120 is coupled with one or more FC host busadapters (HBAs 126 and 128) for coupling the virtual virtualized storagecontroller 100 with a plurality of storage devices (e.g., physicaltarget drives 160.1 through 160.N). Each FC host bus adapter 126 and 128provides a plurality of Fibre Channel ports for coupling to FibreChannel devices including initiator devices (e.g., host 150) and targetdevices (e.g., physical target drives 160.1 through 160.N). Those ofordinary skill in the art will readily recognize that any number of suchFC HBAs may be provided in virtualized storage controller 100 eachproviding any desired number of FC ports for coupling to virtually anynumber of initiator devices and target devices.

In operation, virtual I/O processor 120 receives an I/O request from aninitiator (e.g., host 150) and determines whether the FC targetaddressed by the received I/O request represents a physical FC target(i.e., a specific physical FC target device) or a virtual FC target(i.e., a virtual volume that maps to portions of one or more physical FCtarget devices). Where the I/O request is directed to a specificphysical FC target, standard processing within virtual I/O processor 120and virtualized storage controller 100 processes the request inaccordance with standard Fibre Channel protocols and logic. However,where virtual I/O processor 120 determines that an I/O request isdirected to a virtual FC target, virtual I/O processor 120 interactswith software components 102 through 110 of virtualized storagecontroller 100 to obtain information used by virtual I/O processor 120to complete the received I/O request. In particular, virtual I/Oprocessor 120 first allocates a range of FC exchange IDs by interactionwith the virtual I/O engine exchange pool 108. Exchange pool 108 mayinclude a memory, such as a FIFO memory, to implement a queue structureof available ranges of exchange IDs. During initialization ofvirtualized storage controller 100, a plurality of such predefinedranges may be determined and an entry added to the queue structureindicating each such range as presently available for allocation. Eachrange defines a sequential series of available exchange IDs startingfrom a first exchange ID (M) and extending through a predefined number(N) of sequential IDs (M through M+N−1).

Having so allocated one of the available ranges, virtual I/O processor120 interacts with virtual to physical I/O command tree 104 to obtainaccess to a logical to physical mapping structure. The command treemodule 104 may again comprise a suitable memory and associated logicthat provides a mapping structure in response to decoding of the virtualFC target address identified in the received I/O request. The mappinginformation so retrieved by virtual I/O processor 120 is then utilizedto generate a plurality of physical I/O operations. Each physical I/Ooperation is addressed to a physical location of a correspondingphysical FC target device (e.g., physical target drives 160.1 through160.N). Each of the multiple physical I/O operations utilizes acorresponding one of the multiple exchange IDs in the allocated range ofFC exchange IDs. For example, the originator exchange ID (OX ID) for aphysical I/O operation directed at physical target drives 160.1 mayutilize the first exchange ID of the allocated range (M). The physicalI/O operations directed at each of the subsequent physical targetdevices (160.2 through 160.N) utilize OX ID values corresponding tosequential next exchange IDs of the allocated range (e.g., M+1, M+2,etc. through M+N−1).

Since the multiple physical VO operations may be performed substantiallyin parallel by the corresponding physical target devices 160.1 through160.N, virtual I/O processor 120 includes logic to coordinate theresponses from each of the multiple physical target devices to provide asingle response to the requesting host 150. In particular, virtual I/Oprocessor 120 may include I/O completion module 122 adapted to determinewhether a success or failure response should be sent to the requestinghost 150 based on responses from the plurality of physical FC targetdevices 160.1 through 160.N. If all physical FC target devices 160.1through 160.N return a successful status for their respective physicalI/O operations, I/O completion module 122 returns a good (successful)response to the requesting host 150. Responses other than successfulcompletion including, for example, an FCP DATA frame, an FCP XRDY frame,or an FCP_RSP(Bad) status may require further interaction with softwaremodules 106 and 110. Physical to virtual I/O error resolution module 106is typically implemented as a software component of virtualized storagecontroller 100 and determines whether an FCP_RSP(Bad) status return maybe retried. If so, module 106 interacts appropriately with virtual I/Oprocessor 120 to retry the failed operation. I/O completion module 122of virtual I/O processor 120 awaits the results of such a retriedoperation before communicating a final status to the requesting host150. Virtual I/O context module 110 of virtualized storage controller100 provides mapping information defining the relationship between the“front side” (e.g., host 150 and the controller 100 virtual target) andthe “back side” (e.g., controller 100 as an initiator and a physical FCtarget 160.1 through 160.N). Specifically, the back side exchangeprovided to the target is the OX_ID and the front side exchange is theRX ID. When a frame arrives from the host 150, the RX ID is used as theindex into the virtual I/O context module 110 to obtain the back siderelationship and context for the physical FC target 160.1 through 160.N.In like manner, for frames received at the controller 100 from thephysical FC target 160.1 through 160.N, the OX ID is used to obtain therelationship to front side host 150. The context contains routinginformation (inbound to outbound port) and exchange state that is usedto fault the I/O or return good status to the Host (150).

In communications between virtual I/O processor 120 and the varioussoftware components (102 through 110) of virtualized storage controller100, the starting ID (“main ID”) of the allocated range of exchange IDs(M) may be utilized to identify the relationship among the plurality ofdependent physical I/O operations. In other words, any exchange IDutilized in a physical I/O operation that ranges between a startingvalue of M and an ending value of the range (M+N−1) identifies thecorresponding physical I/O operation as related to other dependent,asynchronous physical I/O operations utilizing exchange IDs in the samerange. The utilization of these predefined ranges therefore simplifiesprocessing of all the components within the virtualized storagecontroller 100 as they relate to the need for identifying theassociation among a plurality of asynchronous, dependent physical I/Ooperations. By contrast, prior techniques utilizing list and queuestructures to associate all the exchange IDs utilized for a sequence ofasynchronous, dependent physical I/O operations required substantialmemory access to determine the relationship. Such access involvednumerous memory accesses to list and queue structures to determine therelationship of one exchange ID to others in a group of related I/Ooperations.

In some embodiments, the exchange ID utilized in communicating responsesto the requesting host 150 (i.e., the responder exchange ID “RX ID”) mayalways be selected as the first exchange ID of the allocated range(i.e., M). In other exemplary embodiment where the enhanced features ofvirtual I/O processor 120 must coordinate with other existing (legacy)logic within the virtualized storage controller 100, it may be desirableto select a different exchange ID to be utilized for communications withthe requesting host 150. Thus, a “primary” exchange ID may be selectedfrom the allocated range of exchange IDs for purposes of communicatingresponses to the requesting host system 150. Primary exchange selectionmodule 124 is therefore operable within virtual I/O processor 120 toprovide logic for selecting an appropriate primary exchange ID based onresponses received from the plurality of physical target devices 160.1through 160.N. To permit such selection of a primary exchange ID (e.g.,the RX ID) primary exchange selection module 124 may determine whichexchange ID of the allocated range of sequential exchange IDs should beselected based on responses from the physical target devices. Thus, anyreceived frames other than a successful completion status from themultiple physical FC target devices 160.1 two 160.N may be passedthrough a primary exchange selection module 124 of virtual I/O processor120 to permit logic therein to select one of the range of allocatedexchange IDs for communication with the host 150 and for compatibilitywith other logic and software with the virtualized storage controller100.

FIG. 2 is a flowchart describing an exemplary method in accordance withfeatures and aspects hereof to improve management of exchange IDsassociated with multiple, asynchronous, dependent physical I/Ooperations in a virtualized storage system. The method of FIG. 2 may beoperable in a virtualized storage system such as described above andFIG. 1. Step 200 represents initialization processing of the virtualizedstorage controller to allow definition of the ranges of sequentialexchange IDs. In general, the number of exchange IDs allocated in eachof the multiple ranges should be a number (N) greater than or equal tothe maximum number of physical target devices that may comprise avirtual volume. In one preferred embodiment, the number of exchange IDsin each range should be a power of two to permit simplified processingfor identifying related exchange IDs by use of bit field masking andshifting operations. In accordance with Fibre Channel standards,exchange IDs are represented by 16 bit unsigned values in the rangebetween 0 and 65535. By way of example, if virtual volumes comprise nomore than 6 physical storage devices, the number of exchange IDs in eachrange (N) may be eight (i.e., a power of two greater than or equal tothe maximum number of physical target devices that may comprise avirtual target). In such an example, 8192 such ranges may be definedwithin the range of 16 bit unsigned values for exchange IDs. The firstor main exchange ID (M) of each of these ranges would then be the set ofnumbers (0, 8, 16, 32, . . . and 65528).

Following initialization of the virtualized storage system, step 202receives a read or write command from an attached host system (i.e. aninitiator device coupled to the virtualized storage system). Thereceived read or write command is addressed to some FC target address.Step 204 next determines whether the received read or write command isaddressed to a virtual FC target or a physical FC target. If thereceived command is addressed to a physical FC target, step 206represents all standard processing within the virtualized storagecontroller to process the received command with the identified physicalFC target device. Such processing is well known to those of ordinaryskill in the art and need not be further detailed here.

If step 204 determines that the received command is addressed to avirtual FC target, step 208 allocates a next available range of exchangeIDs for processing of the received command. As noted elsewhere herein,the available ranges may be maintained in a simple queue or liststructure such that the allocation processing the step 208 merelycomprises “popping” or getting a next item from the list or queue. Step210 then issues an appropriate physical I/O operation to each of theplurality of FC target devices that comprise the addressed virtual FCtarget. Each of the issued I/O operations uses a sequentially next oneof the IDs in the allocated range of exchange IDs.

The issued physical I/O operations are then processed, substantially inparallel, by operation of each of the addressed physical FC targetdevices. Step 212 communicates a completion status to the host 150 usinga selected primary exchange ID from the allocated range of IDs. A singleresponse representative of the status of all the completed physical I/Ooperations is determined and communicated to the host system. Forexample, if all physical I/O operation completes successfully, asuccessful status response is returned to the requesting host system. Bycontrast, if any of the physical I/O operations complete with a failurestatus (after appropriate retry operations) a failure status is returnedto the requesting host system. In communications with the requestinghost system, a primary exchange ID is selected from the allocated range.As noted above, the primary exchange ID in some exemplary embodiment maysimply be selected as the starting exchange ID (M) of the allocatedrange of exchange IDs. In other exemplary embodiments, any one of theexchange IDs in the allocated range may be selected as the primaryexchange ID for purposes of communicating completion status to therequesting host system. Such a selection may be based on any suitablecriteria as dictated by design choices in implementing features andaspects hereof.

Following communications with the host system indicating the success orfailure of the received read or write command, the virtualized storagesystem releases the allocated range of exchange IDs at step 214. Asnoted above, a simple queue or list structure may be used to manage theallocation and release of ranges of exchange IDs. Thus, the processingof step 214 to release the presently allocated range of exchange IDs maycomprise simply adding an entry back to the list or queue indicatingthat the allocated range is once again available.

FIG. 3 is a flowchart providing exemplary additional details of theprocessing of step 200 of FIG. 2 to initialize the virtualized storagesystem by predefining multiple ranges of sequential exchange IDs. Asnoted above, in one exemplary embodiment, each range may comprise arange of sequential exchange ID values (ranging between 0 and 65535 inaccordance with Fibre Channel standards). In one exemplary embodiment, Nmay be a power of two to permit simplified management of the logic toassociate asynchronous dependent physical I/O operations. Utilizing apower of two value for N permits simple bit field shifting and maskinglogic to determine if the exchange ID utilized for any physical I/Ooperation is related to a particular range of exchange IDs (and thusrelates to a particular virtual I/O request). Each such range startsfrom a main exchange ID value (M). Thus, in general, the main exchangeID value for each range is one of a set of values (0, N, 2N, 3N, . . .65536−N). Step 302 then enters each predefined main exchange ID in aqueue or list structure to permit allocation and de-allocation (release)of exchange IDs by simple “push” and “pop” list or queue operations.

FIGS. 4 and 5 are flowcharts providing exemplary additional details ofthe functioning of steps 208 and 214 of FIG. 2 to allocated and release(de-allocate), respectively, a range of exchange IDs. As noted above,the available ranges of exchange IDs may be maintained as entries in alist or queue structure. Thus, step 400 of FIG. 4 provides exemplaryadditional detail of step 208 of FIG. 2 indicating that the allocationof a range of exchange ID values is performed by popping a next entryoff the list or queue of available ranges. The entry so popped providesa main exchange ID (M) such that the values M through M+N−1 may beutilized for dependent, asynchronous, physical I/O operations to processa command directed to a virtual FC target. In like manner, step 500 ofFIG. 5 provides exemplary additional detail of step 214 of FIG. 2indicating that de-allocation (release) of a range of exchange ID valuesis performed by simply pushing a new entry onto the list or queue ofavailable ranges. As above, the pushed entry indicates the main ID ofthe range of IDs to be de-allocated or released. Thus, the range ofexchange ID values from M through M+N−1 is released and available forreallocation. Those of ordinary skill in the art will readily recognizenumerous other embodiments and structures for managing the availabilityof ranges of exchange IDs. Thus, the list or queue structure andpush/pop operations described above with respect to FIG. 3 through 5 areintended merely as exemplary of one possible embodiment. Numerous otherembodiments will be readily recognized by those working skill in the artas a matter of design choice.

FIG. 6 is a flowchart describing exemplary additional details of theprocessing of step 210 of FIG. 2 to issue multiple physical I/Ooperations to appropriate physical FC target devices to effectuate thereading or writing of data from an identified virtual FC target. Avirtual FC target (e.g., a virtual volume) may be either mirrored orstriped. As well known to those of ordinary skill in the art, a mirroredvolume duplicates the same data on multiple devices. A striped volumedistributes portions of data over multiple target devices. Thus, FCphysical I/O operations to perform reads or writes on a mirrored virtualFC target may utilize multicast FC physical I/O operations while astriped FC virtual target command may utilize unicast FC physical I/Ooperations. The multiple multicast physical I/O operations areessentially all identical but for the identity of the particularphysical FC target and the exchange ID utilized by each multicastphysical I/O operation. The multiple unicast physical I/O operationsalso each identify a particular physical FC target and utilize thecorresponding exchange ID within the range of allocated exchange IDs buttypically identify different physical data addresses and providedifferent data in the context of a write operation.

Step 600 of FIG. 6 therefore first determines whether the virtual FCtarget is a striped volume or a mirrored volume. If the virtual FCtarget is a mirrored volume, step 602 issues multiple multicast physicalI/O operations—one to each of the plurality of physical FC targets thatcomprise the identified virtual FC target. Each of the multiplemulticast I/O operations uses a corresponding originator exchange ID (OXID) of the range of allocated exchange IDs. In step 600 determines thatthe virtual FC target identified in the read or write command of therequesting host is a striped volume, step 604 is operable to issuemultiple unicast I/O operations. Each of the multiple unicast physicalI/O operations is addressed to a corresponding physical FC target andeach utilizes one of the exchange ID values in the allocated range asits OX ID.

As noted above when communicating responses to the requesting hostsystem, a primary exchange ID from the allocated range of exchange IDsis utilized for all communications with the requesting host system. FIG.7 provides exemplary additional details of one exemplary embodiment forcommunications with the host system as described above in step 212 FIG.2. Step 700 first selects one of the exchange IDs from the allocatedrange for use as the primary exchange ID in communications with therequesting host system. Having so selected the primary exchange ID,steps 702 through 706 are iteratively operable until all physical I/Ooperations have completed—with either success or failure. Step 702 firstdetects whether a just completed physical I/O operation has failed and,if so, step 704 is operable, if possible, to retry failed operation. Ifno retry or additional retries are feasible or required, the I/Ooperation is simply completed with a failed status. If step 702determines that the just completed physical I/O operation succeeded,step 706 is next operable to determine if all of the dependent physicalI/O operations corresponding to the host read or write command have beencompleted (completed with either failure or success). If not, processingcontinues looping back to step 702 until all related, dependent,asynchronous physical I/O operations have completed. When all physicalI/O operations are completed, step 708 next determines whether any oneor more of the dependent, asynchronous physical I/O operations completedwith a failure. If so, step 710 returns a failure status to therequesting host systems using the previously selected primary exchangeID. If step 708 determines that all dependent, asynchronous physical I/Ooperations completed successfully, step 712 returns a successful status(and/or requested data in the context of a read command) to therequesting host system utilizing the previously selected primaryexchange ID.

As noted above, in some embodiments the enhanced features and aspectshereof may be integrated with existing design choices for othercomponents of the virtualized storage system. In such cases, theselection of a primary exchange ID may need to be coordinated with theother existing logic and software within the enhanced virtualizedstorage system. For example, selection of the primary exchange ID may bedetermined based on the first response received from any of the physicalFC target devices asynchronously performing corresponding physical I/Ooperations in parallel. If a first responding physical FC target deviceindicates successful completion/progress of its physical I/O operation,certain related logic and software within the enhanced virtualizedstorage system may require that the exchange ID of that first physicalI/O operation to respond be utilized for all logic associated with themultiple, dependent, asynchronous physical I/O operations.

FIG. 8 is a flowchart providing exemplary additional details of theprocessing of step 700 of FIG. 7 in accordance with one embodimenthereof where other legacy logic is present that relies on certainselections of the primary XID (RX_ID) for its continued processing ofthe original I/O request from the host. Step 800 first determineswhether the first response is a bad response (i.e., an error indicationfrom a physical FC target in response to its physical I/O operation). Ifso, step 802 selects the X_ID (OX ID) in that received bad response asthe primary X_ID (RX_ID) to be used in all related logic and exchangeswith the initiator (host). Otherwise, step 804 determines whether thefirst received response from a physical FC target is an transmit ready(XRDY) response. If so, step 806 selects the OX ID in that XRDY responseas the primary XID (RX ID) for all further exchanges with the initiatorand other related logic. Otherwise, the first response is a data frame(e.g., responsive to a successful read physical I/O operation). Step 808therefore selects the OX ID of the data frame response as the primaryX_ID (RX_ID) for further exchanges with the initiator and in otherrelated logic.

In other embodiments where the enhanced features and aspects hereof neednot integrate with existing, legacy logic and circuits, simpler logicmay be employed for selecting a primary exchange ID. FIG. 9 is aflowchart providing exemplary additional details of step 700 of FIG. 7to select a primary exchange ID in accordance with such otherembodiments. Step 900 simply selects the main exchange ID (M) of theallocated range of exchange IDs as the primary exchange ID for allfurther communications with the requesting host system.

While the invention has been illustrated and described in the drawingsand foregoing description, such illustration and description is to beconsidered as exemplary and not restrictive in character. One embodimentof the invention and minor variants thereof have been shown anddescribed. In particular, features shown and described as exemplarysoftware or firmware embodiments may be equivalently implemented ascustomized logic circuits and vice versa. Protection is desired for allchanges and modifications that come within the spirit of the invention.Those skilled in the art will appreciate variations of theabove-described embodiments that fall within the scope of the invention.As a result, the invention is not limited to the specific examples andillustrations discussed above, but only by the following claims andtheir equivalents.

What is claimed is:
 1. A method comprising: receiving, by a storagesystem, a data command from a host system, wherein the data command isdirected to a virtual device of the storage system, and wherein thevirtual device comprises a plurality of physical devices of the storagesystem; allocating a range of exchange identifier values to the datacommand; issuing a plurality of I/O operations corresponding to the datacommand, each of the plurality of I/O operations directed to a physicaldevice of the plurality of physical devices of the storage system,wherein the plurality of I/O operations are performed substantially inparallel; and associating an exchange identifier within the range ofexchange identifier values with each of the plurality of I/O operations.2. The method of claim 1, wherein the range of exchange identifiervalues includes a predefined number of exchange identifiers, thepredefined number determined prior to the receiving of the data commandfrom the host system.
 3. The method of claim 2, wherein the predefinednumber is greater than or equal to a maximum number of physical devicesper virtual target.
 4. The method of claim 2, wherein the predefinednumber is a power of
 2. 5. The method of claim 1, further comprising:selecting a primary exchange identifier corresponding to the datacommand; and transmitting a response to the host system using theprimary exchange identifier, the response communicating a status of theplurality of I/O operations.
 6. The method of claim 5, wherein theselected primary exchange identifier corresponds to an exchangeidentifier associated with an I/O operation of the plurality of I/Ooperations.
 7. The method of claim 6, wherein the selected primaryexchange identifier is selected based on the I/O operation generating anerror.
 8. The method of claim 1, wherein the virtual device is amirrored virtual device, and wherein the plurality of I/O operationsincludes a plurality of multicast physical I/O operations.
 9. The methodof claim 1, wherein the virtual device is a striped virtual device, andwherein the plurality of I/O operations includes a plurality of unicastphysical I/O operations.
 10. A storage controller comprising: a firsthost bus adapter communicatively coupled to a host device and operableto receive a data command from the host device; a second host busadapter communicatively coupled to a plurality of physical storagedevices; a virtual I/O processor communicatively coupled to the firsthost bus adapter and the second host bus adapter, the virtual I/Oprocessor operable to: receive the data command from the first host busadapter; determine whether the data command addresses a virtual targetdevice; and when it is determined that the data command addresses thevirtual target device: allocate a range of exchange identifier values tothe data command; generate a plurality of I/O operations correspondingto the data command; associate an exchange identifier from the range ofexchange identifier values to each of the plurality of I/O operations;and issue the plurality of I/O operations to the plurality of physicalstorage devices via the second host bus adapters, wherein the I/Ooperations are to be performed substantially in parallel.
 11. Thestorage controller of claim 10, wherein the first host bus adapter andthe second host bus adapter are a same host bus adapter.
 12. The storagecontroller of claim 10, wherein each of the plurality of I/O operationsis directed to a physical storage device of the plurality of physicalstorage devices.
 13. The storage controller of claim 10, wherein thevirtual I/O processor is further operable to determine a plurality ofpredefined exchange identifier ranges including the range of exchangeidentifier values allocated to the data command, wherein the pluralityof predefined exchange identifier ranges are determined prior to thereceiving of the data command from the first host bus adapter.
 14. Thestorage controller of claim 10, wherein the allocated range of exchangeidentifier values includes a number of exchange identifier valuesgreater than or equal to a maximum number of physical devices pervirtual device of the storage controller.
 15. The storage controller ofclaim 10, wherein the virtual I/O processor is further operable to:allocate a primary exchange identifier to the data command; and transmita response to the host device via the first host bus adapter using theprimary exchange identifier, the response containing a status of theplurality of I/O operations.
 16. The storage controller of claim 16,wherein the primary exchange identifier corresponds to an exchangeidentifier associated with a selected I/O operation of the plurality ofI/O operations, and wherein the selected I/O operation is selected basedon the I/O operation generating an error.
 17. A non-transitory computerreadable storage medium having instructions that, when executed by acomputing device, cause the computing device to: determine a pluralityof predefined ranges of exchange identifiers; receive, from a hostsystem, a data command directed to a virtual device, wherein the virtualdevice comprises a plurality of physical devices; allocate to the datacommand a range of exchange identifiers from the plurality of predefinedranges of exchange identifiers; determine a plurality of I/O operationsfor the data command; associate an exchange identifier from the range ofexchange of identifiers to each of the plurality of I/O operations; andissue the plurality of I/O operations to the plurality of physicaldevices, wherein the plurality of I/O operations are to be performedsubstantially in parallel.
 18. The storage medium of claim 17 havingfurther instructions that cause the computing device to: determine aprimary exchange identifier for the data command based on an I/Ooperation of the plurality of I/O operations producing an error.
 19. Thestorage medium of claim 17, wherein each of the plurality of predefinedranges of exchange identifiers includes a predefined number of exchangeidentifiers.
 20. The storage medium of claim 19, wherein the predefinednumber of exchange identifiers represents a maximum number of physicaldevices per virtual device.